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ABSTRACT 



The “paperless” ship is an idea which has been advocated at the highest levels in the 
Nav^'. The goal is to eliminate the enormous amount of paper required in the normal op- 
eration of a modern naval warship. The ARGOS system under development at the Naval 
Postgraduate school is a prototype solution which uses HyperCard/HyperTalk for proto- 
type development. The operations functional area, including sections for training, sched- 
uling, message generation, and publication management is an important part of this 
development. 
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I. INTRODUCTION 



The Na >7 of today capitalizes on virtually all aspects of modern technology. Nuclear 
poorer, cruise missiles, and satellite communications are but a few of the many examples 
of quantum leaps in technology which have been taken full advantage of by the U. S. Nav}’. 
The ability of shipbuilders and designers to quickly understand the benefits of a new tech- 
nology, and implement that technology in U.S. Warships has been a hallmark of the U.S. 
Na>7 for over a century'. 

In the latter half of the t>\entieth century, the dominant new technology has been the 
computer. Computer technology has been implemented in fire control, guidance, and nav- 
igation systems, greatly enhancing capabilities in those areas. As far as non-tactical uses 
of computers are concerned, the primary implementation has been the shipboard non- 
tactical ADP Program (SNAP). The goals of the SNAP program are; “To collect infor- 
mation only once; to provide maximum automated information systems(either on line or 
off line); to require minimal supply, maintenance and training support; and to require no 
additional shipboard personnel.*'! 

SNAP does not fully capitalize on existing technology in handling non-tactical data 
and information onboard a ship. Today, it is estimated that a small combatant (DD, FF) 
carries onboard upwards of twenty tons of paper (Ref. I: p. 157). Much of this weight is 
in the form of technical, training and maintenance manuals, personnel administration, and 
training records, and various other instructions and publications. Keeping this myriad of 
publications updated and accessible, and simply storing such a volume of 

1 As stated in the SNAP II Organizational Maintenance Management Subsystem desk top 
guide. 
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paper quickJy becomes a problem on a warship that has been optimized for space. On any 
modern combatant, space used to house paper is at a compromise of the mobility, 
habitability and warfighting capability of the ship. It is for these reasons that the 
‘‘paperless ship*’ concept was introduced. 

The goal of the paperless ship is to remove as much paper, if not all paper from a 
ships in order to reclaim the space and weight taken up by the paper for more mission 
critical uses. The ARGOS project is an effort to satisfy the requirements of the paperless 
ship, while maintaining the stated goals of the SNAP program. 

The ARGOS project allows for computerized access, manipulation and creation of 
data normally stored on paper, ARGOS additionally allows commanding officers and battle 
group commanders to instantly access the material, personnel and training readiness of 
their ship or battle group, by accessing the information available through ARGOS. 

ARGOS is a multi-media, object oriented, event driven data base system which com- 
bines textual and graphical data in allowing any use of that data that would be available if 
the data were stored on paper. The ARGOS prototype has been implemented at the Naval 
Postgraduate School using a Macintosh 2 computer, the HyperCard programming envi- 
ronment, and the HyperTalk programming language. At present, ARGOS is divided into 
six different modules, or functional areas; maintenance, operations, supply, administration, 
medical and personnel. This division is not static, but is merely a method of dividing the 
ship's administrative workload for the purpose of prototy pe development. 

The purpose of this thesis is to demonstrate a design and implementation of an oper- 
ations module for the ARGOS system, and to integrate it with the other modules in the 
ARGOS system. 

2 Macintosh, HyperCard, and HyperTalk are registered trademarks of Apple Computer Inc. 
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The thesis is organized as follons: 

• The statement of the problem. Identifying data and operations unique to the module. 

• Programming environment. A brief discussion of HyperCard and HyperTalk. 

• Implementation. A description of how the module was created. 

• Conclusions. Lessons learned from the research, as well as recommended areas for 
further study/review. 

The script listings for prototype stacks developed in conjunction with this thesis are in- 
cluded as Appendicies A through F. 
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II. PROBLEM STATEMENT 



The operations officer on a FFG-7 class ship in the U.S. Nav}’ has been provided »ith 
state-of-the-art detection, surveillance, communications, and weapons systems for his use 
as a watchstander. When he is through with his watch, however, he conducts his business 
for the most part without the help from modern technology’. The responsibilities of the 

operations officer usually include the following: 

• Preparing the ship's employment schedule. 

• Maintaining tactical publications and instructions, operations order, and Naval war- 
fare publications. 

• Serving as the ship's Training Officer. 

• Communications. 

In preparing the ship's schedule (sometimes one year or more in advance), a method 
is needed to make the initial schedule, revise it, and present alternative schedules for final 
approval. When done manually, this process involves many hours of additions, deletions, 
and rewrites, and becomes very labor intensive. The schedule approved is only a proposal, 
and must be forwarded to the fleet and type commanders for approval. The official ship's 
schedule which results is invariably different, which requires generation of the new schedule 
sheets. 

The maintenance of the tactical publications and instructions library' appears to be 
straight fonvard. This includes entering promulgated changes, and keeping custody records 
for each publication. When a publication is needed, its location and change status (that is, 
what changes have been entered) must be determined. This is usually accomplished by 
locating the publication librarian or searching the ship's office in the hope of finding what 
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is needed. Depending on the availability of personnel, this can be time consuming, and 
frustrating exercise. 

The duties of the ship's training officer include: 

• Scheduling standard training requirement (STR) accomplishment. 

• Overall responsibility for divisional and departmental training, and General Militarj' 
Training (GMT). 

• Surface Warfare Officer (SWO) and Enlisted Surface Warfare Specialist (ESWS) 
training. 

• Management of off-ship schools. 

STR scheduling and record involves ship's exercises as specified in Fleet Exercise 
Publications (FXP). The ship generates and submits to the type commander a training 
report periodically. This computer formatted message is entered into the type commander's 
database and the ship receives a report of its training status for the type commander. The 
problems that arise are ensuring that all exercises conducted since the last training report 
are included in the message, and properly updating the database (manually). 

The oversight of divisional and departmental training consists mainly of ensuring 
compliance ^\ith Na\7 training requirements and regulations. These requirements include 
maintaining training records (schedules, attendance records, accomplishment records), les- 
son plans, and qualified instructors lists. On even a small ships, this involves a massive 
amount of paper. Additionally, the formats for attendance records and lesson plans vary 
widely from division to division. SWO and ESWS training require the same records that 
divisional training does, but these records are maintained by the Training Officer per- 
sonally. 

Managing the ships utilization of off ships schools involves knowing the ships require- 
ments for graduates on board, and scheduling school quotas to maintain the proper number 
of graduates onboard. The required graduates information is promulgated by the type 
commander as part of a TYCOM instruction. Tlie scheduling information for convening 
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dates and available quotas is located in the Catalog of Na>7 Training Courses 
(CANTRAC). Searching for a particular course in the CANTRAC, which is distributed 
on microfiche, can be ver} tedious and time consuming. 

The final area of responsibility is communications. Messages transmitted by a ship 
are either free format text messages (similar to a telegram), or formatted messages to be 
entered into the World Wide Militarj' Command and Control System (WWMCCS) data- 
base. Formatted messages follow a strict format which enables the data contained to be 
scanned into the WMMCS database by computer. It follows that the best way to draft 
such messages is via computer. A software system is presently in the fleet to do this, but 
it is a stand alone system used only in generating formatted messages. 

With the exception of formatted message generation and maintenance of individual 
training via service record entries, the functions described above are done manually, often 
at the expense of efficiency. The operations module for ARGOS should address these areas 
and make the performance of these tasks much more effective and efficient. 

The major problem in developing such a system at the Naval Postgraduate School is 
ensuring that the information used in development is current and correct. We are “out of 
the loop” in the promulgation of new directives, and changes in existing instructions. While 
we many draw on personal fleet experience as a guide, ensuring 100% correctness of the 
information used to develop the system is impossible at NFS. 

Another consideration is the security classification of the information. A complete 
system could not be implemented without addressing this issue, especially in the area of 
message generation, since the goal is a working prototype that will demonstrate the capa- 
bilities of the system, these problems have minimal impact on system development. They 
must be addressed however, before a complete system can be implemented. 
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111. THE PROGRAMMING ENVIRONMENT 



This chapter discusses the HyperCard environment and its programming language, 
HyperTalk. HyperCard was developed by Apple Computer for use in the Macintosh family 
of computers. HyperCard version 1.2.1 was used in developing this thesis. 

HyperCard is an event-driven, object oriented programming environment. All 
HyperCard actions are initiated by messages sent to objects [Ref. 2: p.l2]. The basic 
structure of HyperCard is the stack. The term “stack” sliould not be confused \>ith the 
standard last-in first-out data structure normally associated with the word stack in most 
computer applications. In HyperCard, a stack is analogous to a 3x5 card file. Each stack 
is a HyperCard object containing one or more HyperCard cards. Each card consists of 
pictures (graphics), fields, and buttons. Fields, and buttons are also HyperCard objects, 
while pictures are not. Fields are areas where text is read or entered by the user, and where 
text is stored for access and manipulation by HyperCard. A field may be locked to prevent 
modification by the user, or unlocked to allow text to be added or deleted. Buttons are 
primarily designed to perform some action on mouse events (e.g., mouseUp, mouseDown). 
The final HyperCard object is the background. A background has the same structure as 
a card, it may contain graphics, fields, and buttons and is associated \>ith a particular stack. 
A background is shared by cards in a stack, each card is associated with a background. If 
a stack contains only one background, it is said to be homogeneous. If there is more than 
one background in a stack, the stack is heterogeneous. 

Each card, in effect, consists of several layers, At the bottom is the background 
graphics layer. Any graphics common to several cards are placed here. Background but- 
tons and fields come next, each occupying its own layer. The background is visible in all 
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cards associated that particular background. At the card level, the same structure as 
in the background is followed. The graphics is the lowest layer (furthest from view), »ith 
buttons and fields layered above. 

Events in HyperCard cause it to send messages, which in turn may cause some action 
to occur based on the contents of the script of the object receiving the message. Messages 
travel through HyperCard along a message hierarchy, which is a one way path from but- 
tons and fields, to the card, the background, the stack, the home stack, and finally to 
HyperCard itself. The location in the hierarchy at which HyperCard sends a message is 
called the entry point [Ref. 3: p. 376]. When a message is sent HyperCard searches the 
script of the object at the entry point for a message handler for the current message. If a 
message handler is found, it is executed and the message is “trapped” (i.e., it stops its 
journey up the message hierarch}). If no message handler is found, the message continues 
up the heirarchy to the next level. If the message gets to the HyperCard level without 
encountering a message handler, it is lost and no action results. When a handler executes, 
it sends its statements as messages, first to its own object, and then up the message hier- 
archy. A message handier acts on the object in which it is contained, regardless of where 
the message originated. 

Statements in a HyperTalk script may be HyperTalk commands, HyperTalk func- 
tions, user-defined functions, external commands (XCMDs), or external functions 
(XFNCs). XCMDs and XFNCs are written in Pascal, C, or 68000 assembly language and 
compiled separately. They are then added as resources to the stack and may be called by 
HyperCard. XCMDs and XFNCs allow' the programmer to add features to a HyperCard 
stack that are not supported by HyperCard itself. HyperTalk offers a fairly complete set 
of commands and functions, and the ability of the programmer to define his own functions, 
extends the applications of HyperCard. 
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There are several advantages in using the HyperCard environment and HyperTalk for 
the development of the ARGOS operations module. The interface is very intuitive, nhich 
allows the user to quickly learn how to use it. Stacks can be created using HyperCard 
alone without any knon ledge or use of HyperTalk code. Users can rapidly discover the 
power of HyperCard before even familiarizing themselves with the HyperTalk language. 

HyperTalk is very close to the natural language. Commands closely resemble imper- 
ative English (e.g., “put card field 1 into field answer”), and the syntax is relatively for- 
giving. This allows the new' programmer to quickly become comfortable in writing 
HyperTalk scripts, which, in turn allows for faster prototype development. 

HyperTalk is an imperative language, which eliminates the need for compilation and 
“make” commands associated with most high level languages. This greatly speeds up stack 
development and debugging. HyperTalk's imperative nature can have a negative impact on 
execution speed, but execution is still fast enough in most instances. Since HyperTalk is 
object-oriented, scripts tend to be small, easy to understand and fully transportable to other 
objects scripts. The benefits of using HyperCard/HyperTalk as a prototyping tool can be 
summarized in the fact that the time (cost) of development is drastically reduced. 
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IV. IMPLEMENTATION 



A. REPORTS 

The reports subarea is designed to aid in the composition of formatted messages for 
transmission from the ship to higher authority. These messages follow a strict format to 
allow the information contained in the message to be added to the WWMCCS data base. 
The prototype message generator modeled the Oprep-3 message reporting system. 
Oprep-3 messages are transmitted to report incidents of high national or Navy interest. 
Guidelines for submission of Oprep-3 reports are contained in OPNAVINST 3100.6D, 
which was used in the development of this sy stem. Due to their nature, Oprep-3 reports 
are verj time sensitive, with submission of the initial report required within 20 minutes of 
the incident. Additionally, since the reports are formatted, the format must be strictly 
followed. With these requirements in mind, the system was designed to enable the user 
to quickly draft an Oprep-3 message, while at the same time ensuring that format and 
content requirements of OPNAVINST 3100.6D are adhered to. 

When the user selects “Reports” from the operations menu, he then is sent to the re- 
ports stack. The first card in the stack contains a button labeled “Reports”. This button 
uses the HPopUpMenu XCMD3 to implement a heirarchical pop up menu of report types. 
The menu appears when the mouse is down and dragged down towards the bottom of the 
screen from within the button. When the mouse crosses the bottom edge of the button, the 
first menu appears. This menu lists the different report types that may be drafted. The 
menu was taken directly from the formatted message origination system (FMOS), which 
is a stand-alone system currently available in the fleet. The only menu choice implemented 

3 The HPopUpMenu was written by Guy de Picciotto and is available as "freeware" through 
International Datawares Inc., San Jose, CA 
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is “Oprep-3”, When the mouse is dragged into this choice, another menu pops up listing 
the different types of Oprep-3 messages. “Nav^ Blue” is the only choice implemented, and 
is selected by releasing the mouse over the selection. 

When “Na>7 Blue” is selected, the user is sent to the Navy Blue Card. This card lists 
all the required and conditional data elements used in drafting an Oprep-3 Navy Blue 
message. An open card message handler is used to ask the user through the use of dialog 
boxes whether the report is an initial report, an amplification of an earlier report, or the 
final report on the incident being reported. The response is recorded in a global variable 
for later use. The user is also asked to choose the Classification for the message (secret, 
confidential, or unclassified) and this response is also stored in a global variable. The 
classification can be subsequently changed by choosing the “Classification” button on the 
Na\T Blue card. 

Once the open card handler has executed, the user can then either draft the message 
by choosing the appropriate data set, or enter the addressees for the message. The data 
sets are listed on the Na>y Blue card, and are selected by clicking the mouse on the data 
set name. When the data set is chosen, the user is then sent to the “Set Library” stack, 
and the card containing information on the data set chosen. Each data set card has a field 
defined for each message data set. Individual data elements can be either required or op- 
tional. Data element fields can be of a fixed length, variable (with a maximum length), or 
free text (unlimited length). The system must ensure that entered data elements are within 
the format size limits, and that they do not contain illegal characters. This was accom- 
plished by the use of the HyperCard idle message. 

The idle message is sent by HyperCard to the current card when no other sy'stem 
operation is taking place. Each data set card keeps track of the cursor location by putting 
the field name of the active field into a hidden card field. The card sends the idle message 
to that field, and each field has an on idle message handler. The on idle handler in the field 
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checks for illegal characters - namely the slash (/), which is used in the Oprep-3 reporting 
system as a data field delimiter. This checking is done quickly through the use of the offset 
function. The offset function returns the location of an indicated chunk of text in a speci- 
fied container. If the chunk is not in the container, zero is returned. If the offset of the 
single slash in the present field is not zero, then the slash is removed, a beep sounds, and 
the cursor is placed after the location of the deleted slash. 

The length of the active field is also checked in the field's idle handler, if necessary, 
through the use of the “length of’ function. If the user enters an extra character in the 
field, the extra character is deleted, a beep sounds, and the cursor is placed at the end of 
the field. The user can progress through the fields by using the mouse, the tab key, or the 
return key. Each field has a mouse >^ ithin handler to select after the last character of that 
field «hen the mouse is nithin the field. 

Where possible, required data known by the message generating system is automat- 
ically entered into the appropriate data field. The originator of the message (USS Jarrett 
in the prototype), the message type, the report type (initial, amplification, or final) and the 
report serial number are all entered in the appropriate fields by the system. The serial 
number of the message is automatically incremented >\hen the user enters the message card 
(NaAy Blue in the prototype) if the message is cancelled, the proper serial number is re- 
stored. This automatic data entry feature decreases the time required to draft the message. 

Each data set card contains an “Enter’’, “Return”, and “Delete” button. The enter 
button verifies that all required data fields are present. If required data is missing, an error 

message is displayed, and the user is returned to the appropriate data field. If all required 

✓ 

data is present, the data fields, the single slash delimiters, and the double slash end of data 
set marker are entered into the message, adhering to the 69 character per line requirement 
of OPNAVINST 3100.6D, and the user is returned to the Navy Blue card. The delete 
button deletes the data set from the message currently being drafted, and returns the user 
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to the data set card. The user is then returned to the message card to choose the next 
operation. The cancel button simply empties all data fields on the data set card, and returns 
the user to the message card. 

All information on data set content contained in OPNAVINST 3100.6D appears in 
the graphics of the appropriate card. The field delimiters and end of set marker are also 
on the card in the appropriate places. The data entry fields use the courier 12 font, which 
is proportional. If the field can contain a maximum of 20 characters, then any 20 charac- 
ters of courier 12 will occupy the same amount of space. This was important in tailoring 
the physical size of the data fields, allowing only the proper number of characters to be 
displayed. 

The addressees of the message are entered by clicking the “addressees” button on the 
message card. The user is then sent to the addressee card. This card automatically con- 
tains the action and information addressees required by OPNAVINST 3100.6D for the 
message. Additional addressees may be required, depending on the incident being reported. 
These addresses may be entered by clicking on the appropriate address. When all addresses 
have been entered, they many be entered by clicking the enter button, or canceled by 
clicking the cancel button. In either case, the user is returned to the message card. 

When the message drafting is complete, the user may review the message to ensure 
that the information is correct, and to check spelling etc. Manual changes can be made to 
the message at this stage. The message can then be printed, or canceled. If it is printed, 
it is also saved for future reference on its own card. Printing of the field is done by using 
the PrintField XCMD.4 The saved messages can be viewed and deleted through the mes- 
sage file. The message file is accessed via the “Msg File” button located on the top card 
of the reports stack. 

4 Portions of the PrintField XCMD are copyrighted by Think Technologies. It was written 
by Mark Scherfling. 
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B. TRAINING 



1. Ship Training 

Ship training is conducted according to standard training requirements (STRs), 
which describe training evolutions conducted by the ship in various mission areas (ASW, 
AAW, etc.). Mission area STRs are divided into five categories, core, basic, intermediate, 
advanced, and repetitive. Each mission area has an “M-rating^’ which describes the status 
of training readiness in that mission area, M-ratings are from M-1 to M-4, and are de- 
termined by the status of the mission area STRs. When an STR is conducted, a rating of 
M-1 is assigned. For repetitive STRs, the M-rating degrades to M-2, M-3, and finally 
M-4 at intervals defined in fleet exercise publications. For all other STR categories the 
M-1 rating is current for 21 months, at which time it degrades directly to M-4. Due to 
classification considerations, the Mobility (MOB) mission area was the only mission area 
modeled by the prototype. The MOB mission area is further divided into four sub-areas: 
Engineering (MOB-E), Damage Control (MOB-D), Seamanship (MOB-S), and Naviga- 
tion (MOB-N). 

Each STR is uniquely identified by a unique six digit exercise code. Tlie first tno 
digits identify the primary mission area, the third digit identifies the training categor}’, and 
the fifth and sixth digits identify the STR within the particular categorj'. Data for each 
STR are stored using the “item*’ facility of HyperCard. An item is a chunk description 
for a string in a container delimited by a comma. For example, if “Tom,Dick,Harry” were 
in a container, “Tom” would be item 1, “Dick” item 2, and “Harrj” item 3. The item fa- 
cility makes access to data elements a quick, easy and accurate process, especially when 
certain data elements may be of varjing length or omitted entirely. For STR data storage, 
the data items are, in order , exercise code, STR number, Exercise Name, M-rating, com- 
pletion date, expiration date, score, evaluation method, and reporting source. Additionally, 
repetitive STRs have the added items of M-2 degradation period, M-3 degradation, and 



14 



M-4 degradation. These item lists are stored in background fields, with a dedicated card 
for each primarj’ mission sub-area (MOB-E, MOB-D, MOB-S, MOB-N). Background 
fields must be used, as the HyperCard find command will not search card fields. For each 
of these fields containing the STR item lists is a corresponding background field which 
contains the same information formatted for viewing by the user. This apparent redun- 
dancy is necessary’ since data stored as items are in an inappropriate format for \iewing by 
the user. 

To view the STR data base, the user selects the STR option in the training pop 
up menu on the first card of the stack. When this item is selected, the second pop up menu 
offers the option of viewing the data base or drafting a training report (TRAREP). When 
the “View” option is chosen the user is sent to the view card, \^hich has an open card han- 
dler Mhich asks the user to input the mission area to view. Any of the subareas, or the 
entire MOB data base may be viewed. The user can update the database by clicking the 
“Update** button. The updating process involves checking the expiration date of each STR 
in the database currently in view. If the grade has expired, the M-rating is degraded, and 
the expiration date is erased. The date of the most recent update is displayed on the screen, 
and is stored in a field on the appropriate data storage card, the M-rating for the mission 
area in view can be determined by clicking the “M-Rating” button. The new M-rating is 
calculated, displayed, and stored in the same manner as the update information. 

The M-rating operation does not update the expiration dates, and the M-rating com- 
puted is only as good as the data in storage. 

When an STR is accomplished, the fact is recorded by clicking the “Enter Data” 
button. This button asks the user to enter the exercise code, completion date, score, and 
evaluation method. The data is entered in the appropriate data item line, a new expiration 
date is computed, a M-rating of M-1 is assigned, and the string “PDG” is placed in re- 
porting source field. This marks the data as unreported, ensuring that it will be included 
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in the next TRAREP. The corresponding data viewing field is also updated, and the result 
is sent to the viewing field on the card the user is currently viewing. 

When the user desires to draft a TRAREP, this option is selected from the pop 
up menu on the training card. The user is then sent to the “draft TRAREP” card, which 
has three buttons; “Draft”, “Cancel”, and “Print”. The card has an open card handler 
which automatically increments the message serial number and displays it on the screen, 
and records and displays the date-time-group of the message. When the “Draft” button is 
clicked, the entire STR database is searched for the “PDG” flag in the reporting source 
item. When a PDG flag is found, the appropriate data is entered in the TRAREP, and 
the new serial number is placed in the reporting source item. If no STR accomplishments 
are found, the user is notified, and the message drafting process is aborted. The user is 
then asked if there is any air controller data to report through a series of HyperCard 
“Ask” and “Answer” functions. V^'hen the message is completed, it is displayed for review, 
and may be either saved/printed by clicking “Print”, or canceled by clicking “Cancel”. If 
cancel is selected, the database is returned to its previous state (the “PDG” string replaces 
the new serial number), and the user is returned to the training card. The Print operation 
is performed by using the PrintField XCMD, since HyperCard does not directly support 
the printing of fields only. 

2. Personnel Training 

Personnel training is conducted in accordance with the Personnel Qualification 
System (PQS), leading to qualification in various PQS watch stations. The prototype 
provides a mechanism for scheduling PQS training on a quarterly basis. The options 

available to the user are: 

• Schedule creation 

• Schedule modification 

• Recording training accomplishment 
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• Schedule deletion 

• Drawing and printing a training schedule chart. 

Each option is accessed using the pop up menu described previously, and each has its own 
card. 

The schedule creation card has the open card handler which asks for the title of 
the schedule and the calendar quarter of the schedule. When the quarter is entered, a 
calendar for the three months of the quarter is drawn on the card for the user to refer to. 
The user then enters the lesson name and scheduled date of training for up to 15 lessons. 
Data is stored using the item feature, with item 1 being the lesson name, item 2 the date, 
and item 3 either an “S” or a “C” to indicate scheduled or completed training. When the 
schedule is saved, a nen card is created, and the title, quarter, and schedule data are stored 
in card fields. The name of the card is the title of the schedule and the quarter scheduled, 
this allows for the use of the same schedule title in many different quarters. A listing of 
schedule card names is maintained on the “Schedule File” card. When a lesson is com- 
pleted, it is annotated in the “Record Accomplishment” card. The user enters the date the 
lesson was conducted, and the schedule date is replaced by this date, and a “C” is placed in 
item 3 for the specific lesson to signify completion. The schedule is then returned to stor- 
age with the changes added. 

The user can draw a schedule any time after it has been created by selecting the 
“Draw Schedule” option from the pop up menu. The 15 lesson limit on schedules is due 
to the space limitation of the draw function. The drawing process uses the line and text 
painting tools available in HyperCard. Two problems were encountered in implementing 
this function. First, when changing fonts while printing text, all text entered since the last 
mouse click is changed to the new font. Therefore, before changing fonts, the mouse must 
be clicked to ensure all text remains in the desired font. Second, when entering text near 
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other graphics >vith >\hite space surrounding the text character. To avoid tliis, text is en- 
tered first, and graphics afterward. When the schedule chart is completed, it may be 
printed using the HyperCard print card function. 

A major problem >vith the HyperCard date functions Mas also encountered in 
implementing this area. All dates entered must be in the HyperCard “Short date” format 
(e.g., 6/7/89 for 7 June 1989). The problem is the fact that HyperCard Mill accept an 
invalid date (e.g., 2/31/89, 13/13/89) and transform it into some date Mhich is valid format, 
but incorrect in content. This problem was overcome by creating a user defined function 
validDate Mhich ensures that only valid dates are entered into the training data base in both 
the ship training and personnel training areas. 

C. PUBLICATIONS 

The publications subarea ^^as created in the prototype to serve mainly as a stub for 

future development. The facilities provided are: 

• Finding a publication by title. 

• Listing publications by originator. 

• Listing publications by classification. 

• Listing publications by location/custodian. 

• Entering/Deleting titles. 

• Updating custodian or change number information. 

Data is stored in a background field using the item facility, with a corresponding field of 
formatted data for the user to view. The data items are: Title, annex number, appendix 
number, tab number, effecti^ e date of the publication, classification, latest change number 
and custodian. The change number and custodian information can be changed by the user, 
neM' titles can be entered, and titles can be deleted. Data storage is similar to the STR data 

base. All data items are stored in a background field, Mith corresponding formatted data 

✓ 

for vieMing stored in another background field on the same card. When changes are made 
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to the database, both fields are updated accordingly. The prototype is only an inventor}' 
system, since mass storage for the large volume needed to store an entire publication li- 
brary', and security issues are still under research. 

D. SCHEDULES 

The schedule subarea is designed to facilitate the creation of the ship's employment 
schedule, and also to record the ship's actual employment for historical purposes. Infor- 
mation on employment scheduling was taken from Naval Warfare Publication 10-1-10 
Chapter 8. the methods used were very similar to the personnel training scheduling func- 
tions described in section B. Schedules are created, modified, deleted, and drawn in much 
the same manner. There are some significant differences, however. 

A schedule event must have a start date and an end date, they are the same for a one 
day event. Also, events are defined as either occurring in port or underway, and any event 
may be either a major (primary) or concurrent employment. The ship must have one major 
employment schedule for every day of the quarter. Again, the item facility was used, with 
data items as follows: employment abbreviation, start date, end date, major or concurrent 
employment, and inport or undenvay. 

Employment abbreviations are stored in a background field, and a corresponding field 
of formatted data for viewing. These fields do not change, with all data being a reprod- 
uction of table 8-1 of NWP 10 - 1 - 10 . When a schedule abbreviation is entered during 
creation or modification, a check is made using the find function to ensure its validity. If 
it is not a valid entry, the user is notified. On a valid entry, the inport/underway status 
of the event is retrieved and the user is asked to select either major or concurrent employ- 
ment. A check is made to ensure that major employments do not overlap and valid data is 
entered into the schedule. When a major emplo}Tnent is scheduled, an annotation is made 
in a card field signifying that a major employment is scheduled for the appropriate days. 
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When the schedule is saved, this field is checked to ensure major employment for every day 
of the quarter. This field must also be saved >vith the schedule, and retrieved for use when 
modifying the schedule. 

Information on the undenvay and inport dates is stored in the “official” schedule, since 
this information is required by other functional areas. The term “official” is used because 
the user may want to store several alternative schedules for the same time period during 
the schedule planning process. Only the information designated official will be available for 
use by other modules. 
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V. CONCLUSIONS 



The design and implementation of the ARGOS operations module has demonstrated 
not only the feasibility of such a system, but also the strengths of HyperCard/HyperTalk 
as a system prototyping tool. The four subareas modeled are representative of basic areas 
of responsibility of the fleet operations officer. These areas are by no means all inclusive 
or complete. 

Throughout the design process, an effort >vas made to keep the system as user-friendly 
and simple to operate as possible. The ARGOS operations module makes information 
available >vhere and >vlien it is needed. Thus, the user uill be more productive, efficeint, 
and make fe>\er errors. He can spend more time producing (i.e., writing a training schedule 
or operational report) and less time investigating. Formatted messages can be drafted 
quickly and virtually error free. Employment schedules and training schedules can be cre- 
ated and maintained quickly, and information can be extracted easily. The end result of the 
development of the ARGOS operations subarea is that the job efficiency of the people using 
the system will increase substantially. 

Before the operations functional area can be fully implemented, there are several 
problem areas that must be addressed. First and foremost is security, the majority of 
publications, messages, and information the operations officer deals ^>itli on a daily basis 
carr>’ at least a confidential classification. This fact limited the scope of development of 
the operations functional area, since it was desired to keep the ARGOS prototype unclas- 
sified. The solution to the security issue will undoubtedly involve a combination of the use 
of HyperCard's password capabilities and additional physical security measures. 

Another need for full inipleinentation is the requirement to integrate some type of 
ROEM (removable optical erasable medi.'i) and/or CD-ROM (compact disk - read only 
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memory) mass storage device. This capability is especially needed as a storage device for 
publications and instructions. Having reference publications on some computer accessible 
medium would allow rapid searching for subject matter by ke}'words. This capability, like 
all others in the ARGOS system, would greatly increase efficiency. 

There are several areas of development in the operations functional area that are 

worthy of consideration for future research and development: 

• Addressing the problems of computer security associated with the ARGOS system. 

• Complete implementation of the message generation subarea, including computer 
interfaces with the ship's communication system. 

• Development of the training sub-area as its own functional area, or the development 
of a transportable training module for use as an add-on to the administrative func- 
tional area. 

• Development of a mass storage (ROEM/CD-ROM) capability for ARGOS. 

• Design and Implementation of a navigation subarea or functional area. 

Obviously, the above list is not a complete representation of the possible areas of im- 
provement and expansion of the ARGOS system. A major portion of the acceptance of a 
new system such as ARGOS involves salesmanship. Demonstration of other applications 
of Macintosh and HyperCard/HyperTalk capabilities would only serve to increase the 
attractiveness of ARGOS as a system. For example, developing a personnel training 
module, while not directly associated with ARGOS, would make ARGOS more attractive, 
since the personnel training would use the same hardware. Alternatively, making ARGOS 
transportable to the MS-DOS environment would make the system very attractive, since 
that capability already exists in the fleet. 

The primary goal in the development of the ARGOS system is to substantially reduce 
or eliminate the need for paper aboard ship. It is clear that this goal is met in the oper- 
ations functional area. Additionally, significant increase in efficiency will be realized when 
using a fully implemented ARGOS system, since data is more accesible to the user than it 
is when stored on paper. 
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APPENDIX A. OPERATIONS STACK SCRIPTS 



SQUPTS FOR STACK; operations 



** BACKGROUND #1: Operations *************•••**•••***♦**♦♦**♦*♦♦♦ 
on openStack 
hide message box 
show menuBar 
pass opens tack 
end opraStack 

** CARD #1 BUTTON #1; Up 
on mouseUp 
visual effect zoom out 
go to card id 1093 1 of stack argos 
end mouseUp 

** CARD #1, BUTTON #2: Reports ****»♦*■**•*************♦♦♦♦♦♦*♦♦♦♦♦♦ 
on mouseUp 
go to reports 
end mouseUp 

*• CARD #1, BUTTON #3: Training ************************************ 
on mouseUp 
go to training 
end mouseUp 

** CARD #1, BUTTON #4: Publications ************************************ 
on mouseUp 
go to pubs 
end mouseUp 

** CARD #1, BUTTON #5: Schedules ************************************ 
on mouseUp 
go to schedules 
end mouseUp 

** CARD #1, BUTTON #6*. EXIT *’^********************************** 

on mouseUp 
go argos 

end mouseUp 



24 



APPENDIX B. REPORTS STACK SCRIPTS 



SCRIPTS FOR STACK: Reports 



** BACKGROUND #1: Operations ♦*••*•**********•*••••••••••••••••** 

on openStack 
hide message box 
show menuBar 
pass openStack 
end openStack 

** CARD #1‘ reports *♦*♦♦**♦♦**♦*♦♦**♦***********♦*♦*♦♦* 
onopenCard 
global draftflag 
put "false" into draftflag 
endopenCard 

** CARD #1 BUTTON #1’ exit *♦♦•**••••••••*•**•****••••••••••*** 

on mouseUp 
goargos 
end mouseUp 



** CARD #1 BUTTON #2" reports *•••••••*••***•**••***•**•********** 

on mouseDown 
put "Service" into menul 
put return & "Maritime" after menul 
put return & "General Purpose" after menul 
put return & "Air Defense\Control" after menul 
put return & "Flag^DTC" after menul 
put return & "NGFS" after menul 
put return & "Joint Msgs" after menul 

put return & "OpRep 3 J^innacle NucFlashTtinnacle Front Burner JHnnacle Emergency 
Destruction-DisablementJ^iimacle Emergency Evacuation Jinnacle Brcdcen Arrow J^innacleNavy Blue Faded 
GiantNavy Blue Bent SpearNavy Blue Dull Swort^Navy Blue.Unit SitRep" after menul 
get HPopiq)Menu(menul ,0,74,67) 
if it is not zero then 
Put Item 1 of it into TheLine 
put Item 2 of it into Theltem 
If TheLine = 1 and Theltem = 2 then 
push card 
go to card id 4268 
end if 

If TheLine=8 and Theltem=2 then 
push card 

go to card "pinnacle" 
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end if 

If TheLine = 8 and Theltem = 11 then 
push card 

go to card navy_Wue 
end if 

If TheLine=8 and Theltem=4 then 
go to card id 
end if 

If TheLine=I and Theltem=3 thwi 
go to card id 
end if 
end if 

«k 1 mouseDown 

** CARD #I BUTTON #3: Msg File ♦***•••*************''"'"''*•*•••••••**• 

on mouseUp 
push card 

go to card msg_file 
end mouseUp 

•• CARD #1, BUTTON #4: Msg Settings ************************************ 
on mouseUp 
push card 
go to card settings 
end mouseUp 

** CARD #1 BUTTON #5* return 
on mouseUp 
go to operations 
end mouseUp 

CARD #2‘ navy blue 
on c^)enCard 

global msgtype, drafter, msgflag,msgflag2, draftflag, oldnum, semo,-i 
status, class 

put empty into msgtype 
put "OPREP-3" into msgtype 
put empty into msgflag 
put "NAVYBLUE” into msgflag 
put empty into msgflag2 
put into msgflag2 
if draftflag <> "true" then 
put "true" into draftflag 
set lockscreen to true 
put empty into drafter 

put card field orig of card settings into drafter 

put card field orig of card settings into card field orig of card 

addees 

put card field action of card settings & return into -> 
card field action of card addees 

put card field info of card settings & return into card field info— ■ 
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of cardaddees 

set lockscreen to false 

answer "Initial, Amplification, or Final report" with "Initial" or-i 
"Amplification" or Tinal" 
put it into response 

answer "Classification of message ?" with "Secret" or "Confidential"-! 
or"Unclas" 
if it = "Secret" then 
put "S E C R E T" into class 
else 

if it = "Confidential" then 
put "CONFIDENTIAL" into class 
else 

put "UNCLAS" into class 
Old if 
end if 

if response = "initial" then 
put "INTT" into status 

if card field ser_no of card settings is empty then 
put empty into oldnum 
put "001" into semo 

put semo into card field ser_no of card settings 
else 

put card field ser_no of card settings into oldnum 
put char 1 to 3 of oldnum into temp 
put temp + 1 into newnum 
if newnum < 10 then 
put "00" & newnum into semo 
put semo into card field ser_no of card settings 
else 

if newnum < 100 then 
put "0" & newnum into semo 
put semo into card field ser_no of card settings 
else 

put newnum into semo 

put semo into card field ser_no of card settings 
end if 
end if 
end if 

exit openCard 
end if 

if response = "amplification" then 
put "FOLUP" into status 
else 

put "FINAL" into status 
end if 

put card field ser_no of card settings into oldnum 
put the length of oldnum into len 
if len = 3 then 

put oldnum & "A" into semo 

put semo into card field ser_no of card settings 

exit openCard 
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end if 

if len = 4 then 

if char 4 of oldnum = "Z" then 
put char 1 to 3 of oldnum & "AA" into semo 
put semo into card field ser_no of card settings 
else 

put char 1 to 3 of oldnum & -< 

numToChar(CharToNum(char 4 of oldnum) + 1) into semo 
put semo into card field ser_no of card settings 
end if 

exit openCard 
end if 

if len = 5 then 

if char 5 of oldnum = "Z" then 
if char 4 of oldnum = "Z" then 
put char 1 to 3 of oldnum & "AAA" into sotio 
put semo into card field ser.no of card settings 
else 

put char 1 to 3 of oldnum & 

numToChar(CharToNum(char 4 of oldnum) + 1) & "A" into semo 
put SCTno into card field ser_no of card settings 
end if 
else 

put char 1 to 4 of oldnum &—i 

numToChar(CharToNum(char 5 of oldnum) + 1) into semo 
put semo into card field ser_no of card settings 
end if 
end if 
end if 

end openCard 

** CARD #2, BUTTON #1: Return ************************************ 
on mouseUp 

answer "Message will be deleted” with "OK" or "Return" 
if it is "ok" then 

global msgtype,drafier^mo,msgflag 4 nsgflag 2 ,status,draftflag, oldnum 

put empty into msgtype 

put empty into drafter 

put empty into semo 

put empty into msgflag 

put empty into msgflag2 

put empty into status 

put empty into draftfiag 

put oldnum into card field ser_no of card settings 
put empty into oldnum 
set lockScreen to true 
go to card scratch of stack set library 
put empty into card field test 
go to card "navy blue" of stack reports 
pop card 
end if 

end mouseUp 
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** CARD #2, BUTTON #2: exer ************************************ 
on mouseUp 
push card 

set lockScreen to true 
go to card scratch of stack set library 
if "OPER/" is in card field test then 
answer "'OPER' Field used" with "return" 
pop card 

set lockScreen to false 
exit mouseUp 
end if 

go to card exer of stack set library 
end mouseUp 

** CARD #2, BUTTON #3: oper ************************************ 
on mouseUp 
push card 

set lockScreen to true 
go to card scratch of stack set library 
if "EXER/” is in card field test then 
answer "EXER* Field used" with "return" 
pop card 

set lockScreen to false 
exit mouseUp 
end if 

go to card oper of stack set library 
end mouseUp 

** CARD #2 BUTTON #4 ************************************ 

on mouseUp 
push card 

go to card msgid of stack set library 
end mouseUp 

*'*' CARD #2 BUTTON #5‘ ref ************************************ 
on mouseUp 
push card 

go to card ref of stack set library 
end mouseUp 

** CARD #2 BUTTON #6’ ampn ************************************ 
on mouseUp 
push card 

go to card ampn of stack set library 
end mouseUp 

*'*' CARD #2 BUTTON #7* narr ************************************ 
on mouseUp 
push card 

go to card narr of stack set library 
end mouseUp 
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*♦ CARD #2, BUTTON #8; flagword ************************************ 
on mouseUp 
push card 

go to card flagword of stack set library 
end mouseUp 

** CARD #2, BUTTON #9: timeloc ************************************ 
on mouseUp 
push card 

go to card timeloc of stack set library 
end mouseUp 

** CARD #2, BUTTON #10: gentext ************************************ 
on mouseUp 
push card 

go to card gentext of stack set library 
end mouseUp 

** CARD #2, BUTTON #11: rmks ************************************ 
on mouseUp 
push card 

go to card rmks of slack set library 
end mouseUp 

** CARD #2, BUTTON #12: clostext ************************************ 
on mouseUp 
push card 

go to card clostext of stack set library 
end mouseUp 

** CARD #2 BUTTON #13' (jgcl 
on mouseUp 
push card 

go to card decl of stack set library 
end mouseUp 

CARD #2, BUTTON #14: Classification ************************************ 
on mouseUp 
global class 

answer "What is the classification ?" with "Secret" or "Confidential"-! 
or "Unclas" 
if it = "secret" then 
put "SECRET’ into class 
end if 

if it = "confidential" then 
put "CONFIDENTIAL" into class 
end if 

if it = "unclas" then 
put "UNCLAS” into class 
end if 

end mouseUp 
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CARD #2, BUTTON #15: Addressees ************************************ 
on mouseUp 
push card 
go to card addees 
end mouseUp 

** CARD #2, BUTTON #16: Standard settings ***•••••••*•***••*••**•************* 

(m mouseUp 
push card 
go to card settings 
end mouseUp 

** CARD #2, BUTTON #17: Print ••••••••************•••••••••••***** 

on mouseUp 
set lockscreen to true 

global msgtype,drafter^mo 4 nsgflag^sgflag 2 ^tatus,draftflag,oldnum 

put msgflag & & semo into filename 

put empty into msgtype 

put empty into drafter 

put empty into msgflag 

put empty into msgflag2 

put empty into status 

put semo into card field ser_no of card settings 

put empty into semo 

put empty into oldnum 

go to card scratch of stack set library 

put "BT" after last char of card field test 

put card field test into tempmsg 

printField(card field test) 

go to card navy_blue of stack reports 

if tempmsg <> "BT" then 

put filename & return after last char of field listing of card— i 
msg_file 

set lockscreen to true 

doMenu "new card" 

set the name of this card to filename 

go to card filename 

doMenu "new field" 

set style of card field 1 to opaque 

set rect of card field 1 to 0,0,512342 

set textfont of card field 1 to courier 

set textsize of card field 1 to 12 

set lockText of card field 1 to true 

doMenu "new field" 

set style of card field 2 to scrolling 

set reel of card field 2 to 136310380 

set textfont of card field 2 to courier 

set textsize of card field 2 to 12 

doMenu new button 

set icon of card button 1 to 14953 

set rect of card button 1 to 0,303,48,342 
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sei showName of card button 1 to false 
set autoHilite of card button 1 to false 
set style of card button 1 to transparent 

put "on mouseUp" & return & "pop card" & return & "end mouseUp" -• 
into tempscript 

set script of card button 1 to tempscript 
put tempmsg into card field 2 
go to card navy_blue 
set lockscrecn to false 
put empty into draftflag 
choose browse tool 
repeat with j= 1 to 12 
show card field j 
end rq>eat 
go to card reports 
else 

answer "Message is empty" with "return" 
end if 

end mouseUp 

** CARD #2, BUTTON #18; Cut Tape ************************************ 
on mouseUp 
push card 
go to card cut_tape 
end mouseUp 

** CARD #2, BUTTON #19; Review ************************************ 
on mouseUp 
push card 

go to card scratch of stack set library 
end mouseUp 

*♦ CARD #2, BUTTON #20; Cancel ************************************ 
on mouseUp 

global msgtype,drafter,semo^sgflag^sgflag2,status,draftflag,oldnum 

put empty into msgtype 

put empty into drafter 

put empty into semo 

put empty into msgflag 

put empty into msgflag2 

put empty into status 

put empty into draftflag 

put oldnum into card field ser_no of card settings 
put empty into oldnum 
repeat with j = 1 to 12 
show card field j 
end repeat 

set lockScreen to true 

go to card scratch of stack set library 

put empty into card field test 

go to card "navy blue" of stack reports 

pop card 
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end mouseUp 



CARD #2, BUTTON #21: EXIT ************************************ 
on mouseUp 
goargos 
end mouseUp 

•• CARD #3, BUTTON #1: New Button •••••*••*•••••*•******•••••* 

on mouseUp 
popcaid 
end mouseUp 

CARD #4, BUTTON #1: New Button ***•****•♦**♦•***• 

on mouseUp 
pop card 
end mouseUp 

•* CARD #5. BUTTON #1: New Button *••»»*******•***********•****••*•*•<• 

on mouseUp 
pop card 
end mouseUp 
""" CARD #6" addees 
on openCard 

select after last char of card field orig 
end openCard 

** CARD #6, FIELD #1: ORIG ************************************ 
on tabKey 

select after last char of card field action 
end tabKey 

'*'* CARD #6 FIELD #2‘ ACTION 
on tabKey 

select after last char of card field "info” 
end tabKey 

CARD #6 FIELD #3‘ info 
on tabKey 

select after last char of card field "orig” 
end tabKey 

** CARD #6 BUTTON #1* Return 
on mouseUp 
play "RETURN" 
pop card 
end mouseUp 

CARD #6. BUTTON #2: Additional Addee Info **»»»*»*»***»***»•»**•*****••*****•* 
on mouseUp 

push card , 

go to card "addee info” 
end mouseUp 

•• CARD #6, BUTTON #3: Enter ************************************ 

on mouseUp 

global class 
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set lockScreen to true 

put "FROM" & return & card field orig & return & return & "TO" & -i 
return & card field action & return & "INFO" & return & card field -• 
info & return & "BT" & return & class & return into temp 
push card 

go to card scratch of stack "set library" 
put temp before line 1 of card field lest 
pop card 
pop card 
end mouseUp 

** CARD #7: addee info ************************************ 
onopenCard 

if "COMNAVAIRS YSCOM WASHINGTON DC" is in card field "info" of card -i 
addees then 
hide card field one 
else 

show card field one 
end if 

if "CMC WASHINGTON E)C" is in card field "info" of card addees then 
hide card field two 
else 

show card field two 
end if 

endc^nCard 

** CARD #7 BUTTON #1: Return ************************************ 
on mouseUp 
play "RETURN" 
pop card 
end mouseUp 

CARD #7, BUTTON #2: airsyscom ************************************ 
on mouseUp 

if "COMNAV AIRSYSCOM WASHINGTON DC" is in card field "info" of-, 
card addees then 

answer "That address has already been entered" with "return" 
else 

put "COMNAVAIRS YSCOM WASHINGTON DC" & return after last char ^ 
of card field "info" of card addees 
hide card field one 
end if 

end mouseUp 

** CARD #7 BUTTON #3' cmc ************************************ 
on mouseUp 

if "CMC WASHINGTON DC" is in card field "info" of-, 
card addees then 

answ^ "That address has already been entered" with "return" 
else 

put "CMC WASHINGTON DC" & return after last char -i 
of card field "info" of card addees 
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hide card field two 
end if 

end mouseUp 

•* CARD #7, BUTTON #4: NEXT PAGE ************************************ 
on ntouseUp 
go to card "addee info2" 
end mouseUp 

•* CARD #8: ADDEE INF02 
onopenCard 

if "COMNAVSECINVCOM WASHINGTON DC//22D//" is in card field "info" of-, 
card addees then 
hide card field erne 
else 

show card field one 
end if 

if "COMSC WASHINGTON DC" is in card field "info" of card addees then 
hide card field two 
else 

show card field two 
end if 

if "NAVXDIVINGSU PANAMA CITY FL" is in card field "info" of card 
addees then 
hide card field three 
else 

show card field three 
end if 

if "CNO OP ZERO ONE WASHINGTON DC" is in card field "info" of card 
addees then 
hide card field four 
else 

show card field four 
end if 

if "NAVSAFECEN NORFOLK VA" is in card field "info" of card addees then 
hide card field five 
else 

show card field five 
end if 

erxiopenCard 



** CARD #8, BUTTON #1: Return ************************************ 

on mouseUp 
play "RETURN" 
pop card 
end mouseUp 



** CARD #8, BUTTON #2: PREV PAGE ************************************ 
on mouseUp 
go to card "addee info" 
end mouseUp 
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** CARD #8, BUTTON #3: nis ************************************ 
on mouseUp 

if "COMNAVSECINVCOM WASHINGTON DC//22D//" is in card field "info" of-, 
card addees then 

answer "That address has already been entered" with "return" 
else 

put "COMNAVSECINVCOM WASHINGTON DC//22D/r & return after last char-, 
(tf card field "info" of card addees 
hide card field one 
end if 

end mouseUp 

** CARD #8, BUTTON #4: msc *♦♦♦♦**•*******************♦*♦♦♦♦♦♦* 
on mouseUp 

if "COMSC WASHINGTON DC" is in card field "info" of-, 
card addees then 

answer "That address has already been entered" with "return" 
else 

put "COMSC WASHINGTON DC" & return after last char -, 
of card field "info" of card addees 
hide card field two 
end if 

end mouseUp 



** CARD #8, BUTTON #5: dive ♦*************♦♦♦♦♦**♦*♦**♦♦*♦***♦** 
on mouseUp 

if "COMNAVSEASYSCOM WASHINGTON DC" is in card field "info" of card -. 
addees and "NAVXDTVINGSU PANAMA CITY FL" is in card field "info" of-, 
card addees then 

answer "That address has already been entered" with "return" 
exit mouseUp 
end if 

if "COMNAVSEASYSCOM WASHINGTON DC" is not in card field "info" of-, 
card addees and 'T^AVXDIVINGSU PANAMA CITY FL" is not in card field 
"info"of card addees then 

put "COMNAVSEASYSCOM WASHINGTON DC" & return & -. 
"NAVXDIVINGSU PANAMA CITY FL" & return after last char 
of card field "info" of card addees 
hide card field three 
exit mouseUp 
end if 

if "COMNAVSEASYSCOM WASHINGTON DC" is in card field "info" of card 
addees and "NAVXDTVINGSU PANAMA CITY FL" is not in card field "info"-, 
of card addees then 

put "NAVXDTVINGSU PANAMA CITY FL" & return after last char 
of card field "info" of card addees 
hide card field three 
exit mouseUp 
end if 

if "COMNAVSEASYSCOM WASHINGTON DC" is not in card field "info" of-, 
card addees and "NAVXDIVINGSU PANAMA CITY FL" is in card field 
"info"of card addees then 
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